Subscriber quality of experience is an important aspect for both Internet Protocol Television (IPTV) and mobile television (Mobile TV). While there are many factors affecting IPTV service quality, such as picture quality or reliability, a key quality of experience element is how quickly and reliably subscribers can change TV channels.
Conventionally, with IPTV, a subscriber wishing to view a video channel must join a video stream at an appropriate access point within the video stream. This can cause delays during a channel changing procedure in IPTV (i.e. during so-called “channel zapping”), which can result in the subscriber experiencing a slow response time during channel changes.
To improve channel changing response times various techniques, for example Fast Channel Change (FCC) and Fast Content Switching (FCS) have been developed for IPTV and Mobile TV, respectively.
FIG. 1 shows the steps performed during a typical channel change procedure in IPTV, and depict an example scenario with average (worst case) timings based on a 1 second video buffer time and 0.5 second Group of Pictures (GOP) time (GOP being the sequences of I, B and P frames in an IPTV network).
First, a receiver such as a Set Top Box (STB) or television wishing to receive a new channel must first be tuned to the new channel. This involves sending a command to the network and processing the command until tuning has been completed (these steps being shown at times t1, t2 and t3). The first video packets will only be received by the set top box at time t3. i.e. after tuning is complete. In the case of IPTV, the control mechanism typically used to control delivery of multicast traffic to subscribers is the Internet Group Multicast Protocol (IGMP). IGMP commands are used to instruct the upstream equipment to stop sending (“leave”) one channel or to begin sending (“join”) another channel. Therefore, at time t1 the set top box sends an IGMP join command to the network, which results in the network starting to forward the packets for the requested channel to the set top box.
Alternatively, a Real Time Streaming Protocol (RTSP) command can be used instead of an IGMP command to fetch the data, the RTSP command typically being used only to “join” and “leave” certain IPTV channels. RTSP is a control protocol typically used for control of media streaming servers. RTSP is used to typically control unicast delivery (but can also be used for Multicast), whereas IGMP is used to control subscription to multicast groups in the case of multicast delivery.
In the case of traditional broadcast, for example Digital Video Broadcast-Satellite (DVB-S), the receiver (e.g. set top box or television) must tune to the new transponder frequency of the channel or channel bundle. MPEG Transport Stream (MPEG-TS) is typically used in such broadcast systems, where multiple channels are multiplexed into a single transport stream. The transport stream containing the multiple channels is then transmitted on a single frequency (e.g. satellite transponder). The set top box parses the received MPEG transport stream, looking for Program Specific Information (PSI), mainly a Program Association Table (PAT) and a Program Map Table (PMT). These two tables describe the allocation of the channel within the transport stream, i.e. the packet identifiers (PIDs) belonging to the channel, multimedia codecs (MPEG2, MPEG4, . . . etc.) and also which PIDs carry the Program Clock References (PCRs) for the channel. This example assumes a “free-to-air” transmission. In the case of content protected IPTV channels, the set top box also looks for the conditional access table (CAT), which describe the content protection scheme that is used. In such a system the set top box must also decrypt the MPEG transport stream to render the content.
The Program Clock References (PCRs) are provided to assist the set top box in presenting programs on time, at the right speed, and in a synchronized manner. For example, in Europe video frames are intended to be displayed at 25 frames/sec, and each picture in the video stream will carry a time stamp indicating when the picture frame is to be displayed in real time (for example a first frame at 2 pm and a subsequent frame 1/25th second later, etc.). The PCRs synchronize the clock of the receiver with the clock of the sender, and thus are used to control buffering of the transport stream at a receiver.
It will be appreciated that undesirable delays are experienced during the processing of a received transport stream as described above.
For example, while the set top box is acquiring the PIDs there is a delay “X” between time t3 to t4 of typically 100 to 200 msec.
Once the set top box has acquired the PAT and PMT, the set top box then starts parsing for a proper “random access point” (RAP) into the new channel. In the case of MPEG2 Video, this is an Intra Frame procedure. FIG. 1 assumes that a random access point is provided every 0.5 seconds. Again, it will be appreciated that an undesired delay is experienced during the search for the video start, shown in FIG. 1 as a delay “Y” between times t4 and t5.
After the set top box has identified a random access point to the TV channel, i.e. found the video start at time t5, the set top box then starts buffering the received packets. The buffer is intended to take care of the varying media bit rate compared to the (relatively) constant transport rate.
The decoding time for the Intra Frame is provided within the transport stream, and in particular the Decoding Time Stamp (DTS) extension header of the Packetized Elementary System (PES) header. The set top box requires the PCR information to synchronize its system clock with the sender side for decoding. Thus, the MPEG-TS receiver determines the buffering time at the set top box (i.e. the time from when the video start is found at time t5 to the time when the decoding starts) using the PCR. The buffering time, Bt is given as:Buffer time B1=DTS(i)−PCR(i)
where “i” is the first MPEG-TS packet of the video Intra Frame, DTS(i) is the decoding time stamp of the frame, which starts at the ith MPEG-TS packet, and PCR (i) is the receiver system time at the ith MPEG-TS packet. The ith MPEG-TS packet includes the start of a frame.
All PES data for this frame must be transmitted during this buffer time Bt (i.e. (DTS(i)−PCR(i)/300)/90000, since the system clock frequency is 27 MHz (also precision of PCR) and DTS clock frequency is 90 kHz; since PCR(i) represents the system clock in units of 1/27000000 seconds (27 MHz), PCR(i)/300 represents the system clock in units of 1/90000 seconds (90 kHz); since (DTS(i)−PCR(i)/300) represents the buffer time in units of 1/90000 seconds (90 kHz), (DTS(i)−PCR(i)/300)/90000 represents the buffer time in units of seconds). The PES packets for the frame must be transmitted with a bit rate of at least:(len(PES−Data)*90000/(DTS(i)−PCR(i)/300))
Typically, the bit rate is related to the PCRs in the stream as:(PCR(i+N)−PCR(i))/(27000000*N),
where N is equal to the number of packets in the transport stream, and wherein the bit rate of the transport stream is constant between PCT boundaries.
In addition to this decoding time, the set top box requires further time to rearrange the frames from “transmission order” into “display order” (PTS-DTS).
It will therefore be appreciated that an undesirable delay is experienced during this decoding procedure, shown as a delay “Z” between times t5 and t6 in FIG. 1, which can be typically 700 to 1000 msec.
The tuning or channel change procedure described above therefore has a number of undesirable delays. These delays are caused by different steps in the tuning or channel change procedure, including delays during a buffering procedure.